1. Field of the Invention
The present invention relates to emulator support for microcontrollers, and more particularly to an emulator support mode for disabling and reconfiguring time-outs of a watchdog timer.
2. Description of the Related Art
A traditional method of debugging an embedded system or other microcontroller-based device is to use an in-circuit emulator. An in-circuit emulator is primarily used in addressing problems such as signal synchronization, clock frequency, and trace bandwidth. To facilitate in-circuit emulation of code in a microcontroller-based device, breakpoints are commonly set throughout user or application code to be executed on the microcontroller. At each breakpoint, emulator code takes over and is run on the microcontroller in the place of user code. For numerous applications, a watchdog timer is enabled during code execution. Once enabled, a watchdog timer becomes read-only and may not be disabled or reconfigured. After the programmed time-out period, the watchdog timer generates a watchdog time-out unless the timer is refreshed or reset. A watchdog time-out event is an event indicating that software is behaving in a faulty and unexpected way. The occurrence of a watchdog time-out which indicates that a watchdog time-out event has occurred desirably generates a non-maskable interrupt or a reset of the microcontroller or the microcontroller-based device as recovery from the software malfunction. The occurrence of a watchdog time-out which does not indicate that a watchdog time-out event has occurred, however, disrupts code execution. A watchdog time-out is particularly undesirable during an emulation mode of a microcontroller-based device since the state of the device during an emulation mode is ill-suited to processing a watchdog time-out.
Conventional watchdog timers have required repetitive and periodic refreshing during watchdog timer code execution and emulator code execution to prevent a watchdog time-out. During watchdog timer code execution, each refresh of the watchdog timer has been performed by watchdog timer code, and during execution of emulator code, each refresh of a watchdog timer has been performed by the emulator. Generating invasive resets of a watchdog timer within emulator code at each of the appropriate times has been highly difficult. The use of emulators for the debug of watchdog timer code has thus been correspondingly difficult.
Emulator code is designed to interact with watchdog timer code such that following a breakpoint, the user is unable to determine when emulator code is being executed and when watchdog timer code is being executed. Refreshing of a watchdog timer by emulator code undesirably masks to the user whether the watchdog timer code is refreshing the watchdog timer with sufficient frequency to prevent a watchdog time-out. The resets to the watchdog timer defined within the watchdog timer code may not occur or may occur prematurely depending on the location of breakpoints within the watchdog timer code and the duration of the execution of emulator code following the breakpoints.
In an effort to predict how a microcontroller-based device may behave prior to a watchdog time-out, a user has typically set a watchdog timer for a short time-out period and then observed the effect upon the device. The user then extrapolates that effect in an attempt to predict how the device might react prior to the watchdog time-out. This approach yields significant inaccuracies that pose a high degree of software debug uncertainty.